直播回顾 | 千字干货带你入门数据仓库，跑通数据建模全流程（附视频）
本文对“治数训练营”第一期《数据仓库与维度建模》的干货内容进行了总结，同时也挑选了直播间的精彩提问做了Q&A梳理，带大家一起回顾首期课程。
直播回顾视频（上）
01
数据仓库快速入门
数据仓库（Data Warehouse），简称“数仓”，是大数据从业者绕不开的一个概念。“数据仓库之父”Bill Inmon最早提出数仓的概念，认为“数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策”。
此外，大数据架构专家Ralph Kimball在《The Data Warehouse Tookit》一书中，也对数仓进行了定义：“数据仓库是一个将源系统数据抽取、清洗、规格化，然后提交到维度数据存储的系统，为决策的制定提供查询和分析功能的支撑和实现”。
Bill Inmon对数仓的定义更强调整体特性，Ralph Kimball则是从实施流程角度来定义数仓。无论哪个定义，我们都能从中看到企业建设数据仓库的意义重大。企业通过建设数仓，不仅能够将分散在各业务系统的数据进行集中化管理，打破数据孤岛；还能为后续高效分析和应用数据，通过大数据赋能业务发展奠定基础。
02
数仓建设与数据建模
那么，企业如何建设数据仓库？如何建设一个贴合业务需求的、高效、稳定、好用的数据仓库？这就需要考虑数据模型的选择和数据建模的问题。
“数据建模”是指对实体以及实体和实体之间的关系进行数据化描述和抽象的过程。“数据模型”，则是指组织和存储数据的方法。
目前主流的数据建模方法有两种，分别是范式建模和维度建模：
范式建模
范式建模由Bill Inmon提出，指站在企业角度面向主题的抽象，我们一般使用E-R实体关系模型将事物抽象为“实体”“属性”“关系”，来表示事物和事件关联。范式建模并非针对某个具体业务流程中实体对象关系的抽象，它需要建模人员全面地、整体地了解企业的业务和数据，不仅实施周期长，对建模人员的能力要求也比较高。
维度建模
维度建模由Ralph Kimball提出，主张从分析决策的需求出发构建模型，为分析需求服务。因此它重点关注如何使用户更快速地完成数据分析，同时保持较好的大规模复杂查询的响应性能。相较范式建模，维度建模建设周期短，支持敏捷迭代，一般不会对数仓架构做过多复杂的设计。
在构建数仓时，我们要根据具体的数据分析场景和业务处理系统来选择相应的数据建模方法。比如，就OLTP系统（On-line Transaction Processing：联机事务处理）而言，由于其主要是面向随机读写的数据操作，关注事务的处理，因此我们推荐使用OLTP系统及传统数据库的企业通过范式建模的方法来设计数据模型，以解决在事务处理中的数据冗余和一致性问题。而OLAP系统（On-line Analytical Processing ：联机分析处理）面向批量读写数据的操作，不关注事务处理一致性，主要是关注数据的整合以及大数据查询和处理中的性能，因此一般采用维度建模的方法。
具体如何进行范式建模和维度建模呢？我们结合案例分别来看。
03
范式建模方法及实例剖析
首先来看范式建模的基本过程。
在进行范式建模时，我们往往要遵从不同的规范要求设计出合理的模型，这些不同的规范要求就是“范式”。目前行业中存在一范式、二范式、三范式等不同的模型建设规范。越高的范式带来的数据库冗余越小，但是在数据计算方面会更复杂。企业大多采用三范式建模，在保证灵活度以及数据计算速度的同时，降低数据处理的复杂度。
范式建模的过程可以被拆解为以下四步：
1. 抽象出主体
2. 梳理主体之间的关系
3. 梳理主体的属性
4. 画出E-R关系图
比如，我们要使用范式建模的方式设计某课程管理系统的数据模型。
该系统主要用来管理某学校教师、学生和课程等相关数据，涉及课程选修、考试成绩、教师授课、学生班级等方面。那我们首先要梳理出实体，为教师、课程、学生、班级；其次梳理出实体之间的关系，包括教师讲授课程、学生选修课程、学生隶属班级等；再次要罗列出各实体和关系的属性，比如“学生”这个实体的属性有姓名、性别、年龄等，“学生选修课程”这个关系的属性有选修时间、总课时等；第四步，则是画出E-R图，用矩形表示“实体”，用菱形表示“关系”，用椭圆形表示“属性”，以可视化的方式清晰展示出主体和主体之间的关系。
04
维度建模方法及实例剖析
相比范式建模，维度建模稍为复杂，包括事实表和维度表两块内容。
事实表
首先看事实表。事实表分三种，包括事务性事实表、周期性快照事实表、累计快照事实表。
事务性事实表通常用一条记录表示某个时间点发生的事件或行为。比如电商业务场景中的订单支付业务，一般就采用事务性事实表来组织和存储数据。
周期性快照事实表的一条记录描述的则是一个实体在某一段时间内的状态或现状，比如某顾客每月的积分余额就属于一条典型的周期性快照事实表记录。
累计快照事实表的一条记录则是对某业务流程中发生的多个事件的累计记录，一般是为了满足某个流程节点运转效率的统计需求。
我们以一个事务性事实表的设计过程为例来了解事实表的设计方法：
1. 选择与数据分析需求有关的业务过程。“业务过程”是指在业务流程中不可拆分的行为事件。比如，电商业务场景下，购物的业务流程中就包括加购、下单、支付、商家发货、用户确认收货等业务过程。如果我们要分析销售额，那“支付”就是必选的业务过程。
2. 声明粒度。我们要尽量选择最细粒度，精确定义事实表的每一行所表示的业务含义，以确保事实表有最大的灵活性。比如，用户可能在一个订单里面购买多个商品，那每个购买的商品就是一个子订单，我们一般选择将子订单作为声明粒度。
3. 确定维度。维度是指业务过程所处的环境信息，比如用户在某个时间购买了某个店铺的某个商品，那店铺所属行业、商品所在类目等均可以被认为是维度。
4. 确定事实，即确定业务过程的度量指标。比如“支付”这个业务过程的度量指标为支付金额，更复杂的电商业务场景下，可能还包括分摊邮费、折扣金额等指标。
需要说明的是，每个数据仓库都包含一个或者多个事实表，事实表是对分析主题的度量，它包含了与各维度表相关联的外键，并通过Join方式与维度表关联。
维度表
维度表则是用户分析数据的窗口，记录了事实表中相关事务、事件的属性及属性含义。
维度表的设计过程，主要分为以下四步：
1. 选择维度。比如要生成一个商品维度表，那我们选择的维度就是商品维度。
2. 确定主维表。比如要建商品维度表，那主维表就是来自于业务系统的商品表。
3. 确定相关维度表。主维表确定之后，其他的相关维度表也就随之确定。比如商品维度表的相关维度表有商品类目表、所属品牌表、商品所属行业表等。
4. 确定维度属性。这些属性一般来自于主维表和相关维表。我们将主维表和相关维表的属性集成，并对相同属性合并（比如，商品类目表和所属品牌表中可能都会有所属行业属性，那我们就可以对所属行业这个属性进行合并），然后将最终得到的属性放到要生成的维度表里。
此外，本期个推TechDay“治数训练营”还对范式建模与维度建模的基本原则、建模中的常见问题（比如范式建模中的传递依赖问题、维度建模中的缓慢变化维问题等）、数仓分层等进行了详细阐述。
更多精彩内容，猛戳直播回顾视频Get吧！
直播回顾视频（下）
彩蛋：直播间Q&A精选
Q
什么样的数据仓库才算建设得比较完善？
A
数据仓库主要是为数据分析服务。一个完善的数仓首先要满足企业对业务分析的需求。
数仓的建设是一个不断迭代和优化的过程，需要从成本、性能、效率等方面综合考虑，以寻求平衡。一般来讲，在企业业务稳定发展阶段，我们的工作主要以维护现有数仓为主，同时做一些完善优化的工作；对于业务迭代比较快的企业，针对一些探索类的业务分析需求，我们需要对数仓进行新的开发投入。
Q
在数仓设计中，需求方的分析粒度会随着时间和人员的理解以及需求的变化发生很大的变化，如何在数仓建设初期尽可能考虑到这个问题？
A
这就需要数仓建设团队在前期就做好需求调研、业务调研、数据调研等工作。
使用维度建模的情况下，我们要严格遵循事实表的设计原则，在声明粒度时，要尽量选择最新的粒度，并且保留尽可能多的数据维度信息，确保事实表有最大的灵活性。
Q
针对缓慢变化维的问题，是否可以将维度表变成拉链表来解决呢？
A
拉链表也是常用的解决思路，属于插入新行的解决方法，与直播中讲到的插入新行的例子很类似。
不同的是，我们直播中举例的是“商品key”代理主键作为关联事实表的字段，所以可以通过修改“商品key”实现维度变化的处理；而拉链表是通过不修改关联字段，直接在表中增加两个字段start、end来标记数据行的有效时间，在使用时需要先筛选有效的数据行。
相对来说，修改代理主键的方法比较好理解，也更方便用户使用。
Q
数据指标方面，在存在多个业务部门的情况下，如何将相同或者近似名称的指标做统一管理？当出现名称相同但定义不同的指标时，如何处理？
A
该问题涉及到数仓建设规范中的指标命名规范设计，可以在指标命名中避免该问题，比如在命名时增加部门维度等。
另外，在我们“治数训练营”的后续课程中也会有相应的内容介绍，敬请期待。
推荐书目
当一个公司在战略上决定做云计算和大数据服务后，如何将该战略进行逐步分解，最终落地实施？这其中涉及技术构建、运营管理、组织能力建设等一系列活动，有哪些方法论和实践可供借鉴？相信本书能给您带来灵感！
关注个推技术实践微信公众号，
后台回复“数仓”，
获取本期直播课件~